Wireless communications providers are adding capabilities to their networks in order to meet current and projected demand for new and advanced services. In comparison to services that are currently deployed widely, the services are expected to have requirements for lower latency, higher reliability, higher bandwidth, massive connection density, and lower energy use. In considering these needs, three representative service categories have been defined: enhanced mobile broadband (eMBB); ultra-reliable and low latency communications (uRLLC); and massive machine type communications (mMTC). In general, real world use cases are not purely eMBB, uRLLC, or mMTC, but rely on a mixture of the properties of the three. eMBB largely relates to bandwidth, the amount of data that can be transmitted in any given time period. uRLLC largely relates to how quickly data is guaranteed to reach a destination. mMTC relates largely to fully automatic data generation, processing, exchange, and actuation between machines.
FIG. 1, labeled as Prior Art, illustrates real world use cases in the context of eMBB 100, uRLLC 102, and mMTC 101. Bulk data transfer 108 requires massive bandwidth but does not require low latency or high reliability. Viewing of ultra-high definition (UHD) video or 3D video 111 requires massive bandwidth with some reliability and latency requirements and is therefore closer to the eMBB vertex. Smart cities 104, with their plethora of “internet of things” (IOT) devices exemplified by interacting sensors triggering a staggering number of messages, machine interactions, and automated actions are located near the mMTC vertex. Self-driving cars 107 are expected to be particularly reliant on fast and reliable messaging and are therefore closer to the uRLLC vertex. Mission critical IOT 106 can be characterized as low latency, reliable, and massive machine to machine communications. Industry automation 105 can be viewed as communications similar to mission critical IOT, but with more relaxed timing and reliability needs but higher data needs, perhaps for interfacing with humans. Voice/video communications 109, gaming 110, and UHD/3D video 111 are illustrated as clumped together because they all involve communication to or with a human. Human to human communication (voice/video communications 109) have latency/reliability requirements because people are responsive and tend to rely on feedback. Gaming 110 is shown as needing more data bandwidth than voice/video comms 109 but has similar latency/reliability requirements. UHD/3D video viewing certainly requires high bandwidth while caching on at or near the display device results in relaxed latency and reliability requirements. Note that FIG. 1 and the related discussion are intended to be qualitative presentations of representative 5G communications services.
To provide these services, service providers are adapting their infrastructure. Large service providers, such as nationwide providers offering data and voice services, have core networks coupled to a locally deployed radio access networks (RANs). The core networks move data and orchestrate the movement of data based on a number of factors such as the class and quality of service promised to end users, movement of users between communications cells, and network availability. For example, uRLLC data can take priority over eMBB data while data for a low bandwidth customer can be throttled down regardless of network utilization. The RANs wirelessly communicate with user equipment (UE) such as cell phones, smart phones, IOT devices, and other equipment.
FIG. 2, labeled as Prior Art, illustrates a simple RAN. In accordance with recent deployments, the radio functions have been split between a remote radio unit (RRU) 202 and a baseband unit (BBU) 204. The RRU 202 performs basic over-the-air analog radio functions by transmitting signals directly to and receiving signals directly from user equipment (UE) 201. The BBU 204 performs control functions and handles baseband digital signals. The RRU 202 and the BBU 204 can be many kilometers apart and can communicate with a standardized digital protocol, such as CIPR, carried by a front haul 203. CIPR is a transport layer protocol that can be carried by data networks. As such, front haul 203 can be an optical fiber or part of an optical fiber network carrying CIPR data from collocated BBUs to geographically disperse RRUs. Similarly, WiFi can carry CIPR between an RRU and BBU, although such use cases may seem unusual when the RRU/BBU is part of an LTE network. The BBU 204 is connected to a service provider's core network 206 by a backhaul 205. Those familiar with current 4G and LTE communications systems are knowledgeable of the concepts described in this paragraph.
Software defined radio (SDR) technologies have changed RAN architecture. In the past, a radio unit connected the user equipment to the core network. Eventually, the radio unit was split into RRU and BBU although both RRU and BBU were often both deployed at a cell site. The split RRU and BBU exemplify SDR because the BBU can operate in the digital realm and produce digital baseband signals while the RRU translates the digital baseband signals to analog signals at the desired carrier frequency. The separate units allowed the RRU to be hardened and placed close to the antenna while the BBU could be kept inside a cooled structure. Further developments collocated the specialized BBUs into central locations where they were easier to maintain with front hauls connecting BBU to RRU.
SDR splits the analog radio functions from the control functions of a radio. The control functions can be performed by a base band unit (BBU) while the analog radio functions can be performed by a remote radio unit (RRU). Recently, virtual RAN (V-RAN) uses commodity hardware to run BBUs. For example, a normal commercially available desktop or server computer can be repurposed to run virtualized BBUs. A further advance is that the commodity hardware can instantiate virtual machines (VMs) or containers running virtual BBUs. Virtual machines and containers have been central to the management and scaling of large software deployments and cloud based applications. Although the BBUs can be virtualized, the RRUs are, by necessity, specialized devices having analog transmitters, receivers, antennas, and the like.
FIG. 3, labeled as Prior Art, is an illustrative example of a traditional present day telecommunications system core network. The term “core network” is a term of art for telecommunications providers. The core network is the heart of each provider's operations with each provider having its own core network and having dedicated personnel and resources for maintaining and configuring the core network. As can be appreciated from FIG. 3, core networks have been and continue to evolve and are extremely complex. Telecommunications providers are constantly growing and re-engineering their networks to gain competitive advantage. Meanwhile, the core networks are huge. In the US, it is not unusual for a core network to simultaneously provide services to tens of millions of customers located throughout the nation.
LTE (Long Term Evolution) generally refers to a set of standards specifying protocols for digital cellular networks published by the 3rd generation Partnership Project (3GPP) which is a collaboration between groups of telecommunications. In the figures, an element labeled “3GPP” is understood to represent communications equipment conforming to one or more of the 3GPP communications standards. Non-3GPP standards are standards that have not been specified by the 3GPP, such as WiFi. In the context of a provider's core network, such as that of FIG. 3, non-3GPP equipment is either trusted or it is not trusted and the decision to trust is made by the provider. For example, a provider can determine that certain WiFi equipment is trusted non-3GPP equipment while other WiFi equipment is untrusted non-3GPP equipment. Trusted non-3GPP equipment can have having direct access to the provider's core network. Untrusted non-3GPP equipment should not have direct access to the providers core but can have indirect access by way of an evolved packet data gateway (ePDG). The ePDG secures the data transmission between the provider's core network and UE connected over untrusted non-3GPP equipment.
FIG. 4, labeled as Prior Art, illustrates a present day information technology (IT) network 400 that can be used for voice, video, and data communications. The central portion of the network is the TCP/IP/UDP services 401 provided by various layer 2 and layer 3 devices. IP, internet protocol, is the notoriously well-known and common layer 3 (network layer) protocol that passes data packets between source and destination machines, often transiting routers, switches, and other layer 3 and layer 2 devices along the way. TCP and UDP are notoriously well known layer 4 (transport layer) protocols. TCP is directed to the reliable transport of data streams between connection endpoints while UDP is directed to connectionless and unreliable transport of packets. Here, the network layers are referenced using the well-known OSI model with transport layer protocols layered over network layer protocols. For example, TCP and UDP packets are often transported within IP packets. The Internet Engineering Task Force (IETF) has standardized many communications protocols via its Request For Comment (RFC) mechanism. In 1981, version 4 of IP (IPv4) is described in RFC 791. UDP is documented in RFC 768. TCP is documented RFC 793. Later RFCs have refined and built upon the various protocols described herein.
Dynamic Host Configuration Protocol (DHCP) services 405 are typically provided by one or more DHCP servers. DHCP is a standardized network protocol used on Internet Protocol (IP) networks. The DHCP servers dynamically distribute network configuration parameters, such as IP addresses, for interfaces and services. A commodity computer, a router, a residential gateway, or other device running appropriate software can be enabled to act as a DHCP server. DHCP is described in RFC 1541.
Session Initiation Protocol (SIP) is a layer 7 (application layer) communications protocol for signaling and controlling multimedia communication sessions in applications of Internet telephony for voice and video calls, in private IP telephone systems, in instant messaging applications, and related communications. SIP services 401 can be provided by applications and devices communicating over TCP, UDP, and other layer 3 protocols. SIP is important in the context of this disclosure because it arose from the internet community whereas other voice and video communications protocol.
Web Real Time Communication (WebRTC) services 403 can be provided using various communications protocols and Application Programming Interfaces (APIs) for real time communications over peer-to-peer connections. WebRTC can use the layer 7 Real Time Transport (RTP) protocol described in RFC 3550 and is being standardized by the IETF and the World Wide Web Consortium (W3C) The applications enabled by WebRTC include video conferencing, file transfer, chat, and desktop sharing. WebRTC services can be provided by application running on smart phones or commodity computers. For example, recent web browsers support WebRTC. Server side streaming programs can also provide WebRTC services by streaming video and other content.
Many IT type networks, such as that of FIG. 4, are currently undergoing radical architectural changes due to software defined networking (SDN) and network function virtualization (NFV). SDN refers to the separation of the control plane and data plane in a network. The data plane is the fabric over which data is switched and transported. The control plane is responsible for instructing the data plane such that the data is properly sent to its destination. Before SDN, network hardware was expensive and proprietary equipment requiring specialists for configuration and management. With SDN, the data plane can consist of simple devices that switch data from path based on instructions received from the control plane. A standardized protocol such as OpenFlow can carry the instructions between the devices in the control and data layers of a software defined network.
FIG. 5, labeled as Prior Art, illustrates a software defined network (SDN) 500. SDN 500 can host numerous SDN applications such as SDN Application 1 501, SDN Application 2 502, and SDN Application 3 503. An example of an SDN application is a VLAN. A Local Area Network (LAN) is a physical network connecting numerous local devices such as computers, printers, IOT devices, etc. A VLAN mimics a LAN such that the devices can be configured as if they are local to one another even if they a distant. Those familiar with computer networks are familiar with LANs and VLANs. RFC 2674, dated August 1999, discusses VLANs.
The SDN applications can communicate with SDN Controller 504 over North Bound Interface (NBI) 510. Here, the NBI refers to the communications means generally wherein properly formatted data is communicated between SDN Application and SDN Controller. For example, the communications can be an application layer protocol running over IP or can be an API with HTTP, HTTPS, or JSON API calls over TCP. SDN controller 504 can configure the SDN data plane based on requests from the SDN applications 501, 502, 503. SDN controller 504 can communicate with the SDN data plane 511 over SDN Control-Data-Plane-Interface (CDPI) 509.
The SDN data plane 511 is illustrated as having two network elements with each network element providing a data path. Network element 1 505 provides SDN datapath 1 506 while network element 2 507 provides SDN datapath 508. As an example, the network elements 505, 506 can be specialized high speed optical switches providing high speed datapaths over optical fiber to the SDN applications. Note, those practiced in networking and communications realize that physical layer elements such as optical fiber, antennas, and cabling are inherent in the descriptions throughout this disclosure.
FIG. 6, labeled as Prior Art, illustrates a network 600 enhanced with network function virtualization (NFV). Comparing FIG. 5 to FIG. 6, it is seen that many of the network functions of FIG. 5 have been virtualized in FIG. 6. Commodity hardware 601 is running four virtual machines (VMs). As disclosed throughout this application, the VMs discussed throughout this disclosure refer generally to virtualized hardware (hardware virtualization) and to containers running containerized applications. Those practiced in the arts of cloud computing or large application deployment and operation are knowledgeable of hardware virtualization, Operating System (OS) level virtualization, desktop virtualization, application virtualization, and network virtualization.
Hardware virtualization is the creation of guest machines running on host machines. The guest machines can mimic complete hardware platforms or a portion of a hardware platform such as the functionality required to run an operating system. Virtualization hides the physical characteristics of the host machine from the users, presenting instead the functions and characteristics of the guest machine. Often, a hypervisor is responsible for launching and maintaining the guest machines.
OS level virtualization, a.k.a. containerization, refers to isolated user-space instances called containers, partitions, virtual engines (VEs), or jails. Containers often look like real computers from the perspective of programs running in them. A computer program running on an ordinary person's computer's operating system can see all resources (connected devices, files and folders, network shares, CPU power, quantifiable hardware capabilities) of that computer. However, programs running inside a container can only see the container's contents and devices assigned to the container.
Application virtualization typically requires a virtualization layer replacing part of the runtime environment normally provided by the operating system. The virtualization layer intercepts I/O operations of virtualized applications and transparently redirects them to a virtualized location. For example, disk operations can be redirected to a single file. The application is unaware that it accesses a virtual resource instead of a physical one.
Desktop virtualization generally refers to hardware virtualization or containers having access to a windowing environment such that a person can interact with desktop applications running in a container or VM.
Network virtualization combines hardware and software network resources and network functionality into a virtual network. A virtual network is single, software-based administrative entity. Network virtualization can be internal, external, or both. An internal virtual network provides network-like functionality to VMs. An external virtual network combines physical networks or parts thereof into a virtual unit. A VLAN, discussed above, is an example of network virtualization.
Returning now to FIG. 6, VM 1 609, VM 2 606, VM 3 602, and VM 4 604 are running on commodity hardware 601. The VMs can be containers or can be virtualized hardware. VM 3 602 is running a HTTPS server 603. VM 4 604 is running a database 605. VM 2 606 is running network element 1 607 that provides SDN datapath 1 608. VM 1 609 is running SDN application 610 and SDN controller 611. Separately, layer 3 switch 612 is providing SDN datapath 2 613. User equipment (UE) 614 is in communication with HTTPS server 603 which is in communication with database 605. The SDN being properly configured via SDN controller 611, UE 614 cannot access database 605. For example, SDN application 610 can specify two networks with one network privately connecting HTTPS server 603 to database 605 while the second network connects HTTPS server 603 to the outside world such that it can be contacted by user equipment 614.
By some definitions, HTTPS server 603, database 605, and SDN application 610 are examples of network functions. By all definitions, network element 1, layer 3 switch 612, SDN controller 611 are network functions. Network function virtualization is the placement of network functions in VMs. Network element 1 607 running in VM 2 606 is an example of a virtualized network function. SDN controller 611 running in VM 1 609 is another example of a virtualized network function.
FIG. 7, labeled as Prior Art, illustrates a 3GPP Evolved Packet Core network (3GPP EPC) 715 as publicized by the 3GPP. Those familiar with mobile telecommunications networks and standards are familiar with the 3GPP EPC 715. User equipment 1 (UE 1) 701 is an LTE device wirelessly communicating with eNodeB 703. An Evolved Node B (eNodeB), an element of an LTE RAN, is network hardware that communicates directly with mobile handsets. Referring back to the BBU (controller) and RRU (air interface) of FIG. 2, eNodeB hardware can incorporate both the controller and the air interface or it can have separate controller and air interface.
WiFi AP 704 is a wireless local area network (LAN) access point communicating wirelessly with User Equipment 2 (UE 2) 702. WiFi devices are based on the IEEE 802.11 series standards. WiFi AP 704 is non-3GPP equipment because the Institute of Electrical and Electronics Engineers (IEEE) is not the 3GPP. WiFi AP 704 is untrusted non-3GPP equipment because the operator of the network illustrated in FIG. 7 has elected not to trust WiFi AP. ePDG 709 connects WiFi AP 704 to the trusted part of the illustrated network.
The 3GPP Authentication, Access, and Accounting (3GPP AAA) node 708 interacts with the ePDG to control communications between user equipment such as UE 2 702 and Packet Data Network Gateway 2 (PD-GW 2) 710. Authentication refers to confirming the identity of user equipment, such as UE 2 702, or of a person using user equipment. Authorization refers to determining what the user equipment is allowed to do. Accounting refers to tracking and perhaps billing for what the user equipment has done. As such the data connections from 3GPP AAA 708 to ePDG 709 and to PD-GW 2 710 are control connections because the data is control data, not user data. Packet data network gateways such as PD-GW 1 711 and PD-GW 2 710 provide a data connections from the 3GPP EPC 715 to other data networks such as the internet at large or to another provider's network.
The 3GPP Home Subscriber Server (3GPP HSS) 707 is a database containing user related and subscriber related information. 3GPP HSS 707 can also provide support functions related to call/session setup, mobility management, and user authentication and access authorization. The data connection between 3GPP HSS 707 and 3GPP AAA 708 can be considered a control connection with the 3GPP AAA 708 accessing data stored in the 3GPP HSS 707 database. Those knowledgeable of modern telecommunications networks are familiar with 3GPP HSSs and 3GPP AAAs.
The 3GPP Mobile Management Entity (3GPP MME) 706 is a LTE access network's main control node. A 3GPP MME selects the serving gateway for user equipment and changing the selections to a different serving gateway as user equipment roams by moves from eNodeB to eNodeB. A 3GPP MME can enforce roaming restrictions. 3GPP MME 706 can interact with 3GPP HSS 707 to authenticate users/user equipment, determine what QoS is to be provided, determine access levels, and determine access restrictions. A 3GPP MME can page and tag idle user equipment, including retransmitting when needed. Those familiar with modern telecommunications networks are familiar with the function and capabilities of 3GPP MMEs.
The Serving Gateway (SGW) 705 routes and forwards user data packets between eNodeB 703 and the Packet Data Network Gateways (PDN GWs) 710, 711. Using SDN terminology, a SGW provides a datapath for the LTE network while the 3GPP MME is a controller. A SGW can be a mobility anchor for the user equipment during roaming. Referring to FIG. 7, roaming between eNobeBs requires additional eNodeBs connected to SGW 703 and 3GPP MME 706. A SGW can manage and store user equipment contexts such as IP parameters and routing information. Those familiar with modern telecommunications networks are familiar with the function and capabilities of SGWs.
The Access Network Discovery and Selection Function (ANDSF) node 713 is equipment that helps user equipment discover and use non-3GPP access networks. Many current smart phones can communicate using both LTE and WiFi with the WiFi connection being unmetered. For example, UE 1 701 may be using LTE to stream high definition video from the internet 714, which can be costly. ANDSF 713 can help UE 1 701 connect to and stream that video through WiFi AP 704 instead of eNodeB 703. ANDSF 713 is illustrated as within an Administrative PDN 712. Administrative PDB 712 represents the computers used by the network operator's personnel to interact with the 3GPP EPC 715.
The Policy and Charging Rules Function entity (PCRF) 716 supports flow base charging, data flow detection, and policy enforcement. Policy enforcement generally means real-time determination of what data traffic is allowed under what conditions. Charging means determining how to account, for billing purposes, for the traffic that is carried. The 3GPP has a PCRF specification. In the 3GPP EPC 715, the PCRF 716 is illustrated as being on the control plane between the SGW 705 and PDN GW 2 710. The SGW 705 and PDN GW 2 710 also have a direct data plane connection. As such, PCRF 716 can support policy enforcement and charging related to data through or between either SGW 710 and PDN GW 710. Those familiar with standard 3GPP communications networks are familiar with the equipment and function blocks illustrated in FIG. 7.
PDN GW 2 710 contains the Policy Control Enforcement Function entity (PCEF) 717. PCEF 717 communicates with the PCRF 716. It is the PCEF that actually performs the policy enforcement and charging that is supported by the PCRF. As discussed above, policy enforcement generally means real-time determination of what data traffic is allowed under what conditions while charging means determining how to account, for billing purposes, for the traffic that is carried.
Various signals interfaces specified by the 3GPP are indicated in FIG. 7. ENodeB 703 and SGW 705 communicate via S1-U, the data plane of the S1 interface. SGW 705 and 3GPP MME 706 communicate via a S11 interface. 3Gpp MME 706 and 3GPP HSS 707 communicate via a S6a interface. PCRF 716 and PDN GW 2 710 communicate via a Gx interface. SGW 705 and PDN GW 2 710 communicate via a S5 or S8 interface. PDN GW 2 710 communicates out of the 3GPP EPC via a SGi interface. UE 1 701 and eNodeB 703 communicate via a Uu interface. Those familiar with standard 3GPP communications networks are familiar with these and other 3GPP standard signal interfaces.
FIG. 8, labeled as Prior Art, illustrates an Evolved Universal Terrestrial Access Network (E-UTRAN) 801. E-UTRAN is specified by the 3GPP and has eNodeBs 703 linked together with X2 interfaces 802. The E-UTRAN 801 is connected to the 3GPP EPC 715 with an S1 interface 803 which is a backhaul specified by the 3GPP. The S1 interface control plane, S1-C, can communicate with an MME such as 3GPP MME 706. The S1 interface data plane, S1-U, can communicate with a serving gateway such as SGW 705. Each eNodeB 703 in an E-UTRAN has both an air interface and a controller. The X2 interface 802 interconnects a user data plane and a control plane to the eNodeBs 703.
FIG. 9, labelled as Prior Art, illustrates certain IP multimedia Subsystem (IMS) entities. The IMS entities are the CSCF 908, MRF 909, IBCF 920, and TrGW 921. These blocks are illustrated here to simplify the illustrations of other figures and to introduce IMS entities shown in other figures, most notably FIG. 10. The 3GPP has published standards for the IMS, IMS entities, and the communications interfaces between IMS entities. Internally, the IMS is a packet based network using IP. IP, a layer 3 protocol, does not have a concept of a circuit, connection, or communications session because it merely routes packets to their destinations. Higher layer protocols, such as TCP, can handle connection between end points. A core communications protocol within an IMS is Session Initiation Protocol (SIP) which is used for signaling and controlling multimedia communications sessions such as voice or video calls. Within an IMS, the Call Session and Control Function (CSCF) 908 facilitates SIP session setup and teardown and includes three elements. The CSCF includes a Proxy Call Session Control Function (P-CSCF) 915, an Interrogating Call Session Control Function (I-CSCF) 916, and a Serving Call Session Control Function (S-CSCF) 917.
Primarily, the P-CSCF 915 is an entry point to the IMS for the UE. Referring to FIG. 7, PDN-GW 2 710 can communicate SIP messages to a P-CSCF in an IMS using an SGi interface. The Interrogating Call Session Control Function (I-CSCF) 916 performs functions including acting as an inbound SIP proxy server in the IMS, allocating an S-CSCF to the UE upon registration, and acting as a SIP proxy server. After UE registration, the I-CSCF acts as a SIP proxy by interrogating a Home Subscriber Server (HSS), such as 3GPP HSS 707, to determine which S-CSCF a UE is registered to and forwarding SIP messages to that S-CSCF. The Serving Call Session Control Function (S-CSCF) 917 performs session control services for a UE. The S-CSCF 917 performs functions including: being the UE's SIP registrar at the time of registration; forwarding SIP requests to other domains as needed; and validating the UE subscription for the service it is trying to use. In many installations, the P-CSCF 915, I-CSCF 916, and S-CSCF 917 are nodes with a CSCF 908 such that the CSCF 908 can be considered to be a SIP server.
The Interconnection Border Control Function (IBCF) 920 and Transition Gateway (TrGW) 921 are shown in FIG. 9. The 3GPP has published specifications for the IBCF and TrGW. The IBCF 920 is responsible for coordinating communications with a peer IMS. The IBCF 920 can communicate with the IBCF of the peer IMS using the Ici interface. The IBCF 920 can communicate with CSCF 908 or BGCF 912 via a Mx interface. The IBCF 920 can communicate with and control one or more TrGWs using an Ix interface. TrGW 921 forwards media streams to a TrGW within the peer IMS using a Izi interface.
The Multimedia Resource Function (MRF) 909 performs media related functions such as media playing processing independent of application type, playing tones, transcoding, and other functions. The MRF 909 includes two other IMS entities, the Multimedia Resource Function Controller (MRFC) 918 and Multimedia Resource Function Processor (MRFP) 919. The MRFP 919 performs the media related processing functions and is controlled by the MRFC 918.
The Media Resource Broker (MRB) 922 supports the sharing of a pool of heterogeneous MRF resources by multiple heterogeneous applications. The MRB can assign and releases specific MRF resources as requested by applications. The MRB 922 can communicate with an Application Server (AS) 914 using an Rc interface. The MRB 922 can communicate with the S-CSCF 917 using an ISC interface.
FIG. 10, labeled as Prior Art, illustrates major elements and entities within an IMS 901. Many entities and elements have been discussed above and are here shown within an IMS. Other entities and elements are introduced in FIG. 10. The Breakout Gateway Control Function (BGCF) 912 decides how to route telephony sessions having source or destination inside a circuit switched network network. PSTN, 2G, and 3G are considered to be circuit switched networks. The BGCF can route a session to a BGCF in a different IMS or can work with MGCF 911 and MGW 904 within IMS 901 to route the session to a circuit switched network such as PSTN 905 or 2G/3G network 906. The Media Gateway (MGW) 904 is primarily responsible for transcoding a session from the format used by the UE or IMS into that used by the circuit switched network 905, 906. The MGW 904 can be connected directly to a PDN GW such as PDN GW 2 710 using an SGi interface such that session data, such as a voice call, passes directly from 3GPP EPC 715 to MGW 904. The MGW 904 can communicate with the circuit switched network using the data plane of a CS interface. The control plane of the CS interface can connect MGCF 911 to the signaling plane of a circuit switched network such as SS7 907. Some IMS descriptions place a signaling gateway between MGCF 911 and SS7 907.
IMS-Access Gateway (IMS-AGW) 902 regulates and controls the passage of IP packets into and out of the IMS. It can be the entity that is connected to by PDN-GW 2 710 or other entities outside of the IMS. The Application Server (AS) 914 provides services to the UE including audio/video conferencing, multiparty gaming, presence, and content sharing. The Subscriber Location Function (SLF) 913 is a standardized 3GPP entity that is needed when there are multiple HSS such as HSS 707 available. SLF 913 determines which HSS is associated with a particular user profile.
LTE is discussed above, most notably in reference to FIGS. 7 and 8. Further advances in LTE technology relate to LTE in unlicensed spectrum. Three versions of LTE for unlicensed spectrum have been substantially developed. All three versions can interact with 3GPP compliant network elements and entities. LTE-Unlicensed (LTE-U) has been developed by the LTE-U Forum and, in its current form, is intended to share space with WiFi. Share space means that the air interface operates over the same or similar frequencies and has the capability of causing interference. License Assisted Access (LAA) has been standardized by the 3GPP although a certain equipment manufacturer calls a similar technology by the same name. In either case, LAA refers to LTE access technology that can use unlicensed spectrum, such as that used by WiFi, as well as licensed spectrum. LAA avoids interfering with other devices within the unlicensed space by using a listen-before-talk (LBT) protocol. Multefire is a standalone variant of LTE currently intended for small cells. Multefire only uses unlicensed spectrum.
Unlicensed spectrum refers to frequency bands that are not licensed to specific entities but that are available to be shared by whatever entities chose to deploy equipment using those frequency bands. WiFi uses frequencies in the 2.4 GHz and 5.8 GHz unlicensed bands. Other equipment in those bands includes cordless phones, security cameras, remote controls, and video transmitters. Those familiar with radio technologies, particularly the government mandated frequency allocations, are familiar with the various unlicensed frequency bands in various jurisdictions. Recently, spectrum in the 3.5 GHz band (3550 MHz to 3700 MHz) has been authorized for shared wireless access in the US. This band is also referred to as “CBRS” because it has been previously assigned to Citizens Band Radio Service. The details of system operation in US using the CBRS band are specified in Part 96 of the FCC rules. Multefire is a good match for the CBRS band because Multefire is intended for small cells and CBRS is allocated in small cell allotments.
Two of the recent advances in LTE that relate to the CBRS and Multefire are LTE-Frequency Division Duplex (LTE-FDD) and LTE-Time Division Duplex (LTE-TDD). LTE-FDD uses paired frequencies for upload and download while LTE-TDD alternates between upload and download on a single frequency.
Those familiar with modern telecommunications networks are also familiar with the standards and publications of the 3GPP. The figures discussed in this background section and labeled as “Prior Art” draw significantly from 3GPP publications and use 3GPP nomenclature when discussing 3GPP structures and interfaces. Those familiar with modern telecommunications networks will recognize the 3GPP structures and interfaces discussed herein and will know to consult the relevant 3GPP publications for a full understanding of those 3GPP structures and interfaces. The relevant 3GPP publications are hundreds of pages long and the material therein is not reproduced herein. The prior art figures and related discussion are therefore not full and complete specifications but are intended to guide the practitioner to those parts of current telecommunications networks that are most relevant for understanding the aspects of the embodiments claimed below. Those having a knowledge of LTE architectures will immediately recognize that the subsystems and entities taught herein refer to specific structures within core networks and will understand the operation and use of those structures.
Those practiced in the art of telecommunications networks know that functioning communications networks can have multiples of the network elements and entities disclosed in this background section.
Those practiced in the art of telecommunications networks know that a functioning communications network cannot be assembled from the parts described herein by simply combining structures, elements, functions or entities. The prior art network structures, elements and entities communicate with one another using well defined interfaces conforming with interface specifications and the interface specifications detail the protocols accepted by those interfaces. The standardization has been beneficial to network architects because standards-compliant elements and entities can be interconnected in certain specified ways and their interfaces trusted to work. The well-defined interfaces also restrict what structure, element or entity can interact with what other structure, element or entity. As such, network structures, elements and entities will not function unless they are connected to other network structures, elements or entities in certain narrowly defined configurations. Other configurations are unlikely to work.
As can be inferred by this background section, prior art telecommunications networks are well developed and well understood. The prior art telecommunications networks are also complex, expensive, and difficult to maintain and administer. It is therefore difficult for a business to field a telecommunications network and nearly impossible unless that business is a specialized telecommunications provider. Systems and methods that provide non specialist businesses with limited resources to deploy telecommunications networks are needed.